Method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor

ABSTRACT

Methods and systems for facilitating payments between payors and payees are presented. In an example, a plurality of payment commitments made to a payee is accessed. The plurality of payment commitments are made by a plurality of payors to the payee and contribute to a total commitment receivable value of the payee. The total commitment receivable value is calculated based on the plurality of payment commitments made to the payee. A priority of the total commitment receivable value of the payee relative to other total commitment receivable values of other payees is determined. A payment process is initiated based at least in part on the priority of the total commitment receivable value of the payee. The payment process includes a transfer of the total commitment receivable value from one of the payors to the payee.

RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.12/544,919, entitled “Method and System to Facilitate a Payment inSatisfaction of Accumulated Micropayment Commitments to a Vendor,” andfiled Aug. 20, 2009, which is a continuation of U.S. application Ser.No. 10/741,091, entitled “Method and System to Facilitate a Payment inSatisfaction of Accumulated Micropayment Commitments to a Vendor,” andfiled on Dec. 19, 2003, which claims the priority benefit of PCTApplication No. PCT/US03/35950, entitled “Facilitating Micropaymentsbetween a Plurality of Parties,” and filed Nov. 10, 2003. Each of theseapplications is hereby incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to the field of commerceautomation and, more specifically, to a system to enable a payment insatisfaction of accumulated micropayment commitments to a vendor.

BACKGROUND OF THE INVENTION

Electronic payments between transacting parties have become increasinglyprevalent, as the accessibility of technology to enable such paymentshas increased. For example, a majority of vendors are today equipped tohandle credit card and/or debit card transactions. Network-based (oronline) vendors are typically heavily dependent on electronic paymentservices, and may accept a number of electronic payment instruments(e.g., credit cards, debit cards, and other electronic payment services(e.g., the PayPal online payment service)).

A number of companies offer electronic payment (or funds transfer)services (e.g., Visa, Mastercard, American Express, PayPal, etc.). Suchelectronic payment services naturally charge for the provision of suchservices, typically on a per-transaction basis. These transactioncharges are further typically levied against a vendor that is providinggoods or services. While such transaction charges are unattractive tovendors, in many instances the transaction charges are small incomparison to the total transaction value. Further, vendors regard theconvenience benefits to both the purchaser and the vendor as outweighingthe relevant cost.

The transaction charges levied by the various electronic paymentservices are, as noted above, typically per-transaction charges, andfurther often include fixed transaction charges. As a total transactionvalue decreases, the per-transaction charge of course increases as apercentage of the total transaction value, and the attractiveness to thevendor of using such electronic payment services decreases. It is forthis reason that vendors are often reluctant to accept electronicpayment (e.g., via a credit card) where the total transaction value issmall. The use of electronic payment services becomes particularlyunattractive when the transaction costs begin to approach the profitmargins associated with a transaction. Consider for example thesituation where an online vendor is selling electronic content (e.g.,MP3 files) for less than $1. Assuming, for example, a per transactioncharge of $0.10, it will be appreciated that the vendor may be reluctantto receive payment via an electronic payment service because 10% of thetotal transaction value is consumed by electronic payment servicecharges. The problem becomes more acute as the per item value decreases.

With a view to addressing the problem of transaction charges associatedwith so-called “micropayments”, a number of solutions have beenproposed. One such solution is proposed by Jan Chomicki et al, in“Decentralized Micropayment Consolidation”, Proceedings of theInternational Conference on Distributed Computing Systems (ICDS '98),May 1998, Amsterdam, The Netherlands. Specifically, a protocol based onthe concept of debt consolidation in a decentralized network environmentis discussed in this document.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings, in which likereferences indicate similar elements and in which:

FIG. 1 is a diagrammatic representation of a networked transactionenvironment, according to an exemplary embodiment of the presentinvention, within which a client-server architecture is deployed.

FIG. 2 is a diagrammatic representation of a networked transactionenvironment, according to an alternative embodiment of the presentinvention, in which a micropayment system is shown to be deployed as apeer-to-peer system.

FIG. 3 is a block diagram illustrating further detail regardingmicropayment applications, according to one exemplary embodiment of thepresent invention, which form part of the micropayment system.

FIG. 4 is a high-level entity-relationship diagram illustrating varioustables, according to one exemplary embodiment of the present invention,which may reside within a micropayment database associated with themicropayment system.

FIG. 5 is a block diagram illustrating an exemplary commitmentsreceivable table that is populated with values.

FIG. 6 is a flowchart of a method, according to an exemplary embodimentof the present invention, whereby micropayment applications maycalculate a total commitment receivable value, owed to a payee user, andthen allocate that total commitment receivable value to a funding queue.

FIG. 7 is flowchart illustrating a method, according to an exemplaryembodiment of the present invention, to facilitate payments betweenparties for aggregated payment commitments.

FIG. 8 is a flowchart illustration of an exemplary method to calculate arisk-adjusted commitments receivable balance for a particular payeeuser.

FIG. 9 illustrates an exemplary payment commitment interface that may begenerated and presented by the micropayment system.

FIG. 10 illustrates an exemplary payable interface that may be generatedand presented by the micropayment system.

FIG. 11 illustrates an exemplary payment commitment receipt interfacethat may be presented to a user of the micropayment system via arespective web server.

FIG. 12 illustrates an exemplary payable interface, which may bepresented to a payee user, advising the payee user that a commitmentsreceivable balance exceeds a threshold that is eligible for a fundingpayment.

FIG. 13 shows a diagrammatic representation of machine in the exemplaryform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

A method and system to enable the transfer of micropayments to a vendorare described. In the following description, for purposes ofexplanation, numerous specific details are set forth in order to providea thorough understanding of the present invention. It will be evident,however, to one skilled in the art that the present invention may bepracticed without these specific details.

While the term “micropayments” is utilized throughout thisspecification, the present invention is not limited to the processing ofpayments below a specific value. The present invention may findapplication in the processing of payments of any value, and theprocessing of micropayments is described as one use scenario in whichthe invention would find application.

The below-described exemplary embodiment of the present inventionproposes a payment system whereby a payor user is enabled to makepayment commitments to a payee user, these payment commitmentspotentially being for small amounts (e.g., $0.05). The paymentcommitments made by the payor user are then registered against both thepayor user and the payee user. Over time, it will be appreciated thatthe total value of a number of payment commitments made by the payoruser, for example to a number of payee users, will grow. Similarly, thetotal of the payment commitments made to the payee user, potentially bya number of payor users, will also grow. In order to reduce thetransaction costs associated with the processing of these variouspayment commitments, one exemplary embodiment of the present inventionproposes a threshold value at which a payor user may be requested tofund (e.g., make a payment) in connection with a total value thatcomprises an accumulated total of payment commitments made by that payoruser. Similarly, a payee user may, when the accumulated total value ofpayment commitments made to that payee user exceeds a threshold, becomeeligible to receive a payment in satisfaction of the accumulated paymentcommitments. One aspect of an exemplary embodiment of the presentinvention relates to the determination of which payor user should make apayment to which payee user, and a further aspect of the exemplaryembodiment of the present invention relates to the determination of whensuch a payment should be made, and what the value of such a paymentshould be. It will be appreciated that, by accumulating paymentcommitments owed by a payor user, and owed to a payee user, andperforming a single payment transaction (or a reduced number of paymenttransactions) in satisfaction of a number of accumulated paymentcommitments, the transaction costs associated with the satisfaction ofmultiple payment commitment may be reduced.

The exemplary embodiment of the present invention further draws adistinction between unfunded payment commitments (e.g., paymentcommitments for which the payor user has not made a payment insatisfaction thereof), and funded commitments (e.g., payment commitmentsin connection with which the payor user has made a payment).

FIG. 1 is a diagrammatic representation of a networked transactionenvironment 10, according to an exemplary embodiment of the presentinvention, within which a client-server architecture is deployed. Anumber of client-side machines are shown to be coupled, via a network20, to a number of server-side machines and processes. For example, aclient machine 12 is shown to host and execute a first clientapplication, in the exemplary form of a web browser 14, and a secondclient machine 16 is shown to execute a further client 18, which maycommunicate via one or more server-side machines utilizing a publishedApplication Program Interface (API). Each of the client machines 12 and16 is shown to be coupled to the network 20 (e.g., the Internet, LocalArea Network (LAN), a Wide Area Network (WAN)), which may include wired,wireless or some combination of wired and wireless technologies. Thenetwork 20 may furthermore facilitate communications between the clientmachines and the server-side utilizing any one of a number of well-knownprotocols (e.g., HTTP).

Returning now to the server-side, three systems are also coupled to thenetwork 20, namely a settlement system 22, a micropayment system 24, anda trading system 26. While each of the systems 22, 24 and 26 is shown inFIG. 1 to be a separate and distinct system, in alternative embodimentsof the present invention, the components and functions of these systemsmay be integrated into one or more related systems. Each of theexemplary systems 22, 24 and 26 is shown to have a similar three-tierarchitecture, including a database server 28, which facilitates accessto an associated database, one or more application server machines 30,which host and execute respective applications, one or more web servers32 that generate and/or serve web pages (e.g., HTML pages) responsive torequests received from the client-side, and one or more ApplicationProgram Interface (API) servers 34 that provide programmatic access toan associated system. For example, an API server 34 may, responsive to arequest received from the client-side, generate and serve eXtensibleMarkup Language (XML) files to a requesting machine.

Dealing now specifically with the settlement system 22, the relevantapplication server machines 30 host one or more settlement applications42 that enable the transfer of value (e.g., dollar or a proprietarycurrency) between transacting parties. The settlement applications 42are further able to read data from and write data to a settlementdatabase 40, via a database server 28. The settlement system 22 maysupport a payment service, such as the PayPal payment service operatedby Inc., of Mountain View, Calif.

The micropayment system 24 similarly hosts one or more micropaymentapplications 38 on application server machines 30, these micropaymentapplications 38 having read and write access to data stored on amicropayment database 36, via a database server 28. Further detailsregarding exemplary micropayment applications 38 are described infurther detail below.

The trading system 26 hosts one or more trading applications 46 onappropriate application server machines 30, the trading applications 46having read and write access to data stored on a trade database 44, viaa database server 28. The trading applications 46 may include one ormore price-setting applications (e.g., an auction application, afixed-price application, etc) whereby a value for an agreement betweenparties may be established. Other trading applications 46 may include,for example, reputation applications that track feedback andtransactional history information pertaining to a user. Such reputationapplications may also publish reputation information regarding a user,so as to allow users to establish credibility within the trading system26, and have this reputation information published to potential tradingpartners, or to other systems (e.g., the settlement system 22 or themicropayment system 24) for use by these systems in assessing thecredibility, trustworthiness and the risk factors for a particular user.One example of the trading system 26 is the eBay on-line marketplace,operated by eBay Inc., of San Jose, Calif.

FIG. 2 is a diagrammatic representation of a networked transactionenvironment 50, according to an alternative embodiment of the presentinvention, in which a micropayment system is shown to be deployed as apeer-to-peer system, as opposed to the server-based system describedabove with reference to FIG. 1. To this end, FIG. 2 shows the networkedtransaction environment 50 as including user machines 52 and 58, each ofwhich hosts a respective peer-to-peer micropayment application 54 and60. Each of the user machines 52 and 58 is shown to be coupled to anetwork 64 (e.g., the Internet), and the micropayment applications 54and 60 are accordingly able to communicate via the network 64. Each ofthe micropayment applications 54 and 60 further has access to a localmicropayment database 56 and 62, respectively, and may be architecturedand provide the various functions as described in further detail below.

FIG. 2 also illustrates the settlement system 22 and the trading system26 as being server-based systems with which the relevant micropaymentapplications 54 and 60 can communicate via the network 64. In a furtherembodiment of the present invention, the settlement system 22 and/or thetrading system 26 may also be deployed utilizing a peer-to-peerarchitecture, as opposed to the server-based architecture illustrated inFIG. 2. Additionally, have various components of either the settlementsystem 22 or the trading system 26 may, in alternative embodiments, bedeployed as peer-to-peer systems. For example, a peer-to-peer reputationsystem, or a peer-to-peer risk analysis system, could also be utilizedin conjunction with a micropayment system that is server based or isitself a peer-to-peer system.

FIG. 3 is a block diagram providing further detail regarding themicropayment applications 38, according to one exemplary embodiment ofthe present invention, that may be hosted on one or more applicationservers 30 of the micropayment system 24 illustrated in FIG. 1. It willof course be appreciated that the illustrated micropayment applications38 could also form modules, or sub-applications, of a peer-to-peer,stand-atone micropayment application 54 that executes on a user machine52.

The exemplary micropayment applications 38 include a payable commitmentregister module 70, which operates to register payment commitments thatmay be made by a payor user utilizing the micropayment system 24. Forexample, the micropayment system 24 may provide one or more userinterfaces whereby a payer user can identify a payee user to which thepayer user wishes to make a payment commitment, and utilizing which thepayor user may also specify a value e.g., a monetary value) for therelevant payment commitment. One embodiment of the present inventionclassifies payment commitments as either being unfunded (e.g., therelevant payer user has not made an actual payment to satisfy one ormore payment commitments) and funded payment commitments (e.g., thepayor user made a payment in satisfaction of one or more paymentcommitments).

The payment commitment register module 70 may communicate with the webserver 32 and/or the API server 34 so as to send commitment information(e.g., to be included within a marked up language document), and toreceive payment commitment information from a payer user. The paymentcommitment register module 70, on receipt of the payment commitmentinformation, further operates to record this information withinappropriate tables within the micropayment database 36. Such tables mayinclude, for example, a commitments payable table 94 and a commitmentsreceivable table 96, which are discussed in further detail below withreference to FIG. 4.

Similarly, a receivable commitment register module 72 operates toreceive commitment information pertaining to a payment commitment to apayee user, and to register this payment commitment information withinan appropriate table, or tables, within the micropayment database 36.For example, the receivable commitment register module 72 may recordreceivable commitment information. within a commitments receivable table96, which is described in further detail below with reference to FIG. 4.

Both the payable commitment register module 70 and the receivablecommitment register module 72 communicate with a recurring commitmentmodule 74. The recurring commitment module 74 is responsible forgenerating recurring payments commitments as defined by a payor user(for generating or recurring commitment requests as may be defined by apayee user), and for communicating appropriate commitment information tothe register modules 70 and 72, responsive to which the register modules70 and 72 will create and/or update records within the appropriatetables. Consider for example that a particular payor user may wish tomake a monthly payment commitment to a specified payee user (e.g., forsubscription to a particular service). The recurring commitment module74 then handles such a recurring commitment.

A threshold adjustment module 76, according to one exemplary embodimentof the present invention, facilitates the specification of, orspecifies, thresholds that trigger a funding transaction (e.g., theinitiation of a payment process) in satisfaction of payment commitmentsthat have been registered within the micropayment system 24. Forexample, a payable threshold may be specified in connection with payablecommitments of a payor user, so that when the total value of paymentcommitments made by the payor user exceeds the payable threshold, apayment process is initiated whereby the payor user funds the relevantunfunded payment commitments.

Similarly, a receivable threshold may be specified by the thresholdadjustment module 76, the receivable threshold being a threshold totalvalue that, when exceeded by the value of payment commitments made to apayee user, renders the payee user eligible to receive value insatisfaction of the payment commitments.

In one embodiment of the present invention, the threshold adjustmentmodule 76 may simply operate to allow an administrator of themicropayment system 24 to specify one or more threshold values (e.g.,$5.00) as either a payable threshold or a receivable threshold, forexample. For example, an administrator of the micropayment system 24 mayspecify different thresholds that are applicable to individual payorusers or payee users, or even various pairs of payor/payee combinations.

In another embodiment of the present invention, the threshold adjustmentmodule 76 may allow individual users to specify payable and/orreceivable thresholds, for example within the constraints of certainminimum and maximum values, which would be applicable to the relevantuser.

In yet a further embodiment of the present invention, the thresholdadjustment module 76 may automatically calculate payable and/orreceivable thresholds, utilizing the various information sources. Forexample, where the micropayment system 24 is aware that a certainsettlement system 22 will be utilized in connection with a particularfunding event, the threshold adjustment module 76 may adjust thresholdsdependent on transaction charges levied by the relevant settlementsystem 22. Consider the specific example where a settlement system 22increases transaction charges associated with funding events. In thiscase, the threshold adjustment module 76 may raise thresholds so as tomaintain the transaction charges as a predetermined maximum percentageof a funding value. In another exemplary embodiment, the thresholdadjustment module 76 may adjust thresholds dynamically based on whethera particular payee user has failed to achieve a predetermined rate ofpayment commitments. For example, the threshold adjustment module 76 mayautomatically lower a funding receivable threshold so as to prevent therelevant payee user from having to wait an unacceptable amount of timeprior to having payment commitments funded. Also, where a payor user isnot making payment commitments at a predetermined rate, the thresholdadjustment module 76 may also lower the funding payable thresholdassociated with that user so as to extract funding within an acceptabletime period.

The threshold adjustment module 76 may also take into account thecharacteristic or attribute information associated with a payor or payeeuser in assessing a threshold associated with that user. For example,where historical or reputation information associated with the userindicates an increased or decreased risk associated with obtainingfunding from a payor user, the threshold adjustment module 76 mayautomatically adjust a funding payable threshold for that user. In yetanother exemplary embodiment, the threshold adjustment module 76 mayincreased or decreased the threshold over time. For example, thethreshold may start at a certain level (e.g., $5.00), and be reduced bya predetermined amount each month (e.g., $1.00 per month) to a minimumacceptable transaction value, to ensure that the payor user iseventually made liable to make a funding payment, even if the fundingpayment is very small.

The threshold adjustment module 76 may also specify thresholds withvarying resolutions. For example, the threshold adjustment module 76 mayspecify thresholds to be applied on a system level across themicropayment system 24. The threshold adjustment module 76 may alsospecify thresholds to be specified at a user-level, or even at a fundingtransaction level, depending on various circumstances.

FIG. 3 shows the threshold adjustment module 76 being coupled to athreshold assessment module 80, the threshold assessment module 80operating to assess whether a commitment payable total, for a commitmentreceivable total, exceeds a specified threshold. Operation of thethreshold assessment module 80 is described in further detail below withreference to FIG. 6.

The micropayments applications 38 are, in one exemplary embodiment, alsoshown to include a receivable calculation module 78 that operates tocalculate a total commitment receivable value for a payee user,utilizing a risk profile associated with a user (e.g., the payee user).In other embodiments of the present invention, the calculation of thetotal commitment receivable value may take other risk information intoaccount. The invention is accordingly not limited to the utilization ofa risk profile associated with a user, but may include the utilizationof any information from which a risk determined or inferred.

The receivable calculation module 78 is shown to communicate with a riskassessment module 81, which determines the risk profile associated witha user (e.g., the payee user). For example, the risk assessment module81 may author a risk profile for a user (or otherwise calculate a riskvalue for utilization within the micropayments system 24) utilizinghistorical and reputation information. The historical and/or reputationinformation utilized by the risk assessment module 81 may be obtainedlocally from the micropayment system 24, or may be obtained from othersources, such as for example reputation information obtained from thetrading system 26, and historical payment information obtained from thesettlement system 22. The risk assessment module 81 may also obtaininformation from third party information vendors, such as Equifax andcredit score organizations.

A wide variety of other information sources may be utilized by the riskassessment module 81 in calculating risk values (e.g., a risk profilefor a user) for utilization within the micropayment system 24. Forexample, a type of merchandise or service offered by a particular usermay be relevant. For example, gaming or pornography services aretypically at a higher risk of default by payor users. A geographiclocation of a payor or a payee user may also be relevant. It should benoted any combination of information associated with any type of user,or any party to a particular transaction, may be utilized by the riskassessment module 81 in assessing risk. The assessment risk mayfurthermore be utilized beyond the calculation of the total commitmentreceivable value for a payee user, and may be utilized forrisk-adjusting, other payment values and other purposes within themicropayment system 24, for example as described below.

The risk assessment module 81 is also shown to provide input to thethreshold adjustment module 76, so as to enable the module 76 to utilizea risk profile in adjusting threshold values associated with the user,if warranted.

The micropayment applications 38 also include a communication module 82to enable the communication of various types of information between themicropayment applications 38 and other applications (e.g., thesettlement application 42 and the trading applications 46 illustrated inFIG. 1), as well as the communication of messages (e.g., emails, SMSmessages, Instant Messages (IMs), etc.) to users of the micropaymentsystem 24. For example, the communication module 82 may communicateinstructions to settlement applications 42, as part of a paymentprocess, to initiate the transfer of funds from a payor user to a payeeuser. The communication of such instructions may be performedautomatically on instruction from a payment allocation module 84, or maybe performed upon receiving instructions from a user for the relevantfunds transfer.

The communication module 82 may also receive communications from otherapplications. For example, the settlement applications 42 maycommunicate back to the communication module 82 that funds havesuccessfully been transferred from a payor user to a payee user,responsive to which the micropayment applications 38 may registercertain commitments as being funded. To this end, the communicationmodule 82 is shown to be in communication with the register module 70and 72, an as to enable these modules to register commitments as funded,when appropriate and as confirmed by a settlement application 42.

The communication module 82 is also shown to be in communication withthe threshold adjustment module 76 so as to enable the thresholdadjustment module 76 and the risk assessment module 81 to sendcommunications to, and receive communications from, external systemssuch as the settlement system 22 and the trading system 26.

A payment allocation module 84 operates, in one exemplary embodiment ofthe present invention, to instruct the automatic transfer of funds froma payor user to a payee user. For example, a payor user may have definedpreferences in terms of which payment commitments are automaticallyfunded upon the total of such commitments exceeding a funding payablethreshold. Further, the payor user may have specified preferences as towhich payee user is to receive the relevant funds, or have specifiedcriteria in terms of which the payment allocation module 84 mayautomatically identify a payee user to which the funds should beallocated. For example, a specific user may define preferences whereby,upon the total of payment commitments for the payor user exceeding athreshold, such commitments are funded by making a payment to a charityorganization that qualifies to receive the funding.

As will be described in further detail below, in one exemplaryembodiment, receivable commitments, when exceeding a funding receivablethreshold, may be placed in a funding queue by the receivablecalculation module 78 and by the threshold assessment module 80. In thisembodiment, the payment allocation module 84 may operate variousalgorithms to determine which of the eligible payees within the fundingqueue is to be funded next, or upon occurrence of a specific event. Forexample, the payment allocation module 84 may allocate funding to thefunding queue based on a simple first in, first out principle.Alternatively, the payment allocation module 84 may apply moresophisticated criteria to the selection of payees from within thefunding queue.

FIG. 4 is a high-level entity-relationship diagram illustrating varioustables 90, according to one exemplary embodiment of the presentinvention, which may reside within the micropayment database 36. Thetables 90 include a user table 92 in which is stored contact and otherinformation specific to each user. A commitments payable table 94maintains a record of each payment commitment made to a specific user,and includes identifiers identifying the payor user, the payee user, anamount of the commitment, the date on which the commitment was made, adescription of the commitment, an indication of whether the commitmentis funded or not, and an indication as to whether the commitment isrecurring.

Similarly, a commitments receivable table 96 stores records for eachpayment commitment receivable by a particular user, and records the sameinformation recorded within the commitments payable table 94.

It will be appreciated that by maintaining separate commitments payableand commitments receivable tables 94 and 96, these tables may beutilized to perform double-entry verification. In an alternativeembodiment, the commitments payable table 94 and the commitmentsreceivable table 96 may be combined into a single commitments table.

A settlements table 98 is populated with records for each fundingtransaction between a particular payor user and a particular payee user.The records within the settlement table 98 may be generated frominformation retrieved from the settlement system 22, and may also beutilized by the register modules 70 and 72 to flag entries within thetables 94 and 96 as funded responsive to a particular fundingtransaction.

The tables 90 further includes a user thresholds table 100, which storesa funding payable threshold and a funding receivable threshold for eachuser for which a record exists within the user table 92. As describedabove, in one exemplary embodiment of the present invention, payable andreceivable thresholds may be specified at a user-level. In analternative embodiment of the present invention, a system thresholdstable 102 may store funding payable and funding receivable thresholdsthat are applicable at a system level within the micropayment system 24.Of course, both user thresholds and systems thresholds table 100 and 102may exist, and the recorded thresholds may be selectively applied by thepayment allocation module 84, depending on predetermined criteria.

The tables 90 also include a reputation table 104 that is populated withrecords that include feedback and history information for a particularuser. For example, the reputation table 104 may include transactionfeedback information, payment feedback information, membership durationinformation, external credit or identification verification information,and affiliate information. As described above, information within thereputation table 104 may be internally generated within the micropaymentsystem 24, or may be received via the communication module 82 fromexternal sources and systems (e.g., the settlement system 22 and thetrading system 26).

FIG. 5 is a block diagram illustrating an exemplary commitmentsreceivable table 96 that is populated with values. As shown, variouscommitments are flagged as either being funded or unfounded, dependingon whether a relevant payor has performed a funding transaction thatapplies and covers the relevant payment commitment.

It should be noted that the user table 92 might, in one exemplaryembodiment, reflect a commitment payable balance and a commitmentreceivable balance. The receivable calculation module 78, based oninformation contained within the commitments payment table 94 and thecommitments receivable table 96, may periodically update these balances.

FIG. 6 is a flowchart of a method 110, according to an exemplaryembodiment of the present invention, whereby the micropaymentapplications 38 may calculate a total commitment receivable value, owedto a payee user, and then allocate that total commitment receivablevalue to a funding queue. Specifically, the commitments receivable table96 provides input, in the form of raw commitments receivableinformation, to the receivable calculation module 78. The receivablecalculation module 78 deploys a risk model 112 to calculate arisk-adjusted commitments receivable value total. The risk model 112utilizes information retrieved from the reputation table 104 to author arisk profile, associated with the relevant payee user, and calculatesthe risk-adjusted commitments receivable total as a function of theauthored risk profile. In one embodiment, the risk profile is appliedonly to the unfunded portion of the raw commitments receivable total, inview of the uncertainty regarding the funding of this portion of thecommitments receivable total. In other embodiments of the presentinvention, the risk profile that is applied to the unfunded portion ofthe raw commitments receivable total is not particularly associated withthe payee user, but may be applicable across the micropayment system 24as a whole, or may be calculated based on the payor users associatedwith the unfunded payment commitments.

The function of the risk profile that is applied by the receivablecalculation module 78 may be a simple function (e.g., a simplepercentage calculation), or may be a more complex function that takes anumber of factors into consideration. For example, the risk profile (orother at risk value) may be calculated utilizing any of the informationtypes specified above. Further, the function of the risk profile (orrisk value) that is applied by the receivable calculation module 78 maybe the subject of continuous improvement or adjustment, either by anadministrator of the micropayment system 24 or by its own machinelearning.

The risk-adjusted commitments receivable total is then communicated fromthe receivable calculation module 78 to the threshold assessment module80, which makes a determination as to whether the risk-adjustedcommitments receivable total exceeds a threshold that qualified thereceivable total for funding. In making this assessment, the thresholdassessment module 80 may utilize information contained in the thresholdtables 100 or 102, described above with reference to FIG. 4. As noted,the thresholds may be applied on a system-level, a user-level or atransaction-level.

In the event that the threshold assessment module 80 determines that therisk-adjusted commitments receivable total is qualified to receivefunding, the relevant receivable total is entered into a funding queue114. Each entry within the funding queue 114 records the risk-adjustedcommitments receivable total, the payee user, the date on which thereceivable total was entered into the funding queue, and a priority. Inone embodiment, the payment allocation module 84 may determine thepriority. Specifically, the payment allocation module 84 may prioritizeeach of the entries within the funding queue 114 based on a first in,first out priority scheme, or a more complex priority scheme. Forexample, entries for which the payee is a specific type of organization(e.g., a charity), or is identified as a priority payee, may beprioritized ahead of other entries. In other embodiments, the priorityscheme may be utilized to prioritize entries within the funding queue toensure that the payees do not wait an unacceptable period of time priorto receiving funding.

FIG. 7 is flowchart illustrating a method 120, according to an exemplaryembodiment of the present invention, to facilitate payments betweenparties for aggregated payments commitments. The method 120 commences atblock 122, with the presentation of the payment commitment interface toa payor user. FIG. 9 illustrates an exemplary payment commitmentinterface 160, which may be presented at block 122. As will be notedfrom FIG. 9, the payment commitment interface 160 may include a payeeidentification field 162, within which a payor user may identify a payeeuser, and an amount field 164, into which a payor user can input a valueassociated for the relevant commitment. The payment commitment interface160 also includes a recurrence section 168, which allows the payor userto identify the commitment as being recurring (e.g., using yes/no radiobuttons), and allows the payor user to specify a recurrence date withina recurrent date field 169, and the recurrence period within arecurrence period field 170. In other exemplary embodiments, theinterface 160 may provide other mechanisms for indicating recurrence,such as number and frequency of payment, e.g, “make 25 commitments of$0.10 each, one commitment per day.”

Returning to FIG. 7, at block 124, the communication module 82 receivespayment commitment information from the payor user (e.g., via the webserver 32 or the API server 34), the payment commitment informationincluding an identifier for the payee user, an amount, a date and theabove discussed recurrence information.

At block 162, the payment commitment register module 70 registers apayment commitment, based on the payment commitment information, againstthe payor user within the commitments payable table 94. Similarly, thereceivable commitment register module 72 registers the paymentcommitment against the payee user in the commitments receivable table96. Further, the receivable calculation module 78 may calculate andupdate the commitments payable and commitments receivable balances foreach of the payer and the payee users within the user table 92, based onthe received payment commitment information.

At decision block 128, as are described above, the updated commitmentsreceivable balance that is calculated at block 126 and reflected in theuser table 92, may be a risk-adjusted commitments receivable balance (ortotal) as calculated by the receivable calculation module 78.

Moving on to decision block 128, the threshold assessment module 80,subsequent to the updating of the commitments payable balance,determines whether the commitments payable balance for the payor exceedsa pre-determined threshold funding payable threshold (e.g., specific ata user-level or a system-level threshold). In the event that thecommitments payable balance for the payor user does not exceed athreshold, the method 120 then terminates at block 130,

On the other hand, should the commitments payable balance for the payoruser exceed the funding payable threshold, at decision block 132, thepayment allocation module 84 makes a determination whether a payee user(e.g., a vendor) exists with a commitments receivable balance that isequal to, or exceeds, the commitments payable balance of the payor user.As noted above, the commitments receivable balance is, in an exemplaryembodiment, a risk-adjusted commitments receivable balance. Thedetermination performed by the payment allocation module 84 at decisionblock 132 may include the payment allocation module 84 performing asearch of the funding queue 114 to identify entries having a commitmentsreceivable total that is satisfiable by the commitments payable balanceof the payor user. In performing the search of the funding queue 114,the payment allocation module 84 may also consider the priority dataassociated with each entry when attempting to identify an eligible payeeuser.

In the event that the payment allocation module 84 is successful inidentifying a payee user at decision block 132, the method 120 proceedsto block 134, where a payment process is initiated to effect a fundingpayment from the payer user to the located payee user.

In various embodiments of the present invention, the initiation of thepayment process at block 134 may take various forms. For example, themicropayment system 24, may at block 134 present a payable interface172, an exemplary embodiment of which is illustrated in FIG. 10, to thepayor user, the payable interface 172 communicating to the payor userthat (1) his or her commitments payable balance exceeds the threshold,and that (2) the payor user is now required to make a funding payment tothe located payee user. In one exemplary embodiment of the presentinvention, the payment allocation module 34 may, at decision block 132,in fact identify a number of payee users that are eligible to receivethe funding payment. In this exemplary embodiment, the payable interface172 may present to the payor user a list 174 of eligible payee users,together with a mechanism (e.g., a radio box) to select at least one ofthe eligible payee users to receive the funding payment.

The payable interface 172 also shown in FIG. 10 to include a “proceed topayment service” button 176, which is user-selectable to divert thepayor user to the settlement system 22. The settlement systemconveniently allows the payor user to make the funding payment to theselected payee user. Accordingly, selection of the button 176 may causethe micropayment system 24 utilizing the communication module 82, tocommunicate payor user identification information, payee useridentification information, amount information and funding amountinformation to the settlement system 22. Where the settlement system 22is web-services enabled, this information may be received via a relevantAPI server 34. The settlement applications 42 of the settlement system22 may then initiate a flow whereby the funding transaction payment maybe completed.

In an alternative embodiment of the present invention, at block 134, thepayment allocation module 84 may automatically communicate instructionthat cause the funding payment to be paid to the payee user, withoutmanual intervention or approval by the payor user. For example, thepayment allocation module 84, utilizing the communication module 82, maycommunicate instructions to the settlement system 22 to perform thefunding payment into an account of the payee user.

Where the settlement system 22 is utilized to complete the payment atblock 134, the settlement system 22 may communicate confirmationinformation back to the micropayment system 24, this information beingreceived by the communication module 82, and then provided to theregister modules 70 and 72. Responsive to receiving confirmation of thefunding payment, the register modules 70 and 72 may then flag thepayment commitments within the commitments tables 94 and 96 as beingfunded.

Moving on from block 134 of the method 120, the method 120 en terminatesat block 136.

Returning to decision block 132, in the event that the paymentallocation module 84 is unable to locate a payee user within the fundingqueue 114 with a commitments receivable value that is greater than orequal to the commitments payable balance, the payment allocation module84 proceeds to attempt to locate a payee user with a commitmentsreceivable balance that is greater than or equal to a predeterminedthreshold. In the exemplary embodiment of the present invention thatincludes the funding queue 114, the threshold assessment module 80 willhave already identified, and placed within the funding queue 114, allcommitments receivable balances that exceed an appropriate fundingpayable threshold. In this case, the payment allocation module 84selects a next commitments receivable balance, from the funding queue114 and according to the employed priority scheme, to receive thefunding payment. In an alternative embodiment to the present invention,the threshold assessment module 80, at decision block 178, performs ananalysis on the commitments receivable balances (e.g., risk-adjusted orotherwise) with a view to identifying eligible payee users, where afterthe payment allocation module 84 may dynamically select from theeligible payee users.

In the event that the payment allocation module 84 is unable to locatean eligible payee user at block 138 (e.g., the funding queue 114 isempty), the method 120 proceeds to block 136 and ends. On the otherhand, if at least one eligible payee user is identified, the method 120progresses to block 140, and a process whereby the payor user pays thepayee user the funding payment is initiated. The method 120 then loopsback from. block 140 to decision block 128.

FIG. 8 is a flowchart illustration of an exemplary method 127, which maybe performed within the context of the block 126 of FIG. 7. The method127 is to calculate a risk-adjusted commitments receivable balance for aparticular payee user. The receivable calculation module 78 may performthe method 127.

The method commences at block 142 with the identification of the fundedcommitments to the payee by performing a search of the commitmentspayable table 94.

At block 144, the module 78 sums identified funded commitments to thepayee user, to thereby generate a funded commitments receivable total.

At block 146, the module 78 identities unfunded payment commitments tothe payee, again by performing a search of the commitments payable table94.

At block 148, the module 78 sums the unfounded payment commitments tothe relevant payee user to generate an unfunded commitments receivabletotal.

Moving on to block 150, utilizing the risk model 112, the receivablecalculation module 78 applies a risk profile function to the unfundedcommitments receivable total, thereby to generate a risk-adjustedunfunded commitments receivable total.

At block 152, the receivable calculation module 78 then sums the fundedcommitments receivable total, and the risk-adjusted funded commitmentsreceivable total, to generate the risk-adjusted commitments receivablevalue total, which may then be written into the user table 92, orotherwise stored within the micropayment system 24. The method 127 thenends at block 154.

While the risk adjustment is described above as being performed withrespect to unfunded commitments to a payee user, the present inventionis not so limited. In alternative embodiments of the present invention,the risk adjustment may be performed with respect to an entirecommitments receivable total, and need not be performed only on theunfunded component thereof.

FIG. 11 illustrates an exemplary payment commitment receipt interface180 that may be presented to a user of the micropayment system 24 via arespective web server 32. Specifically, the interface 180 may bepresented to a payee user in order to advise the payee user of receiptof a payment commitment from a payor user. To this end, the interface180 may identify the payor user to the payee user via a payor field 182,and may also communicate the amount of the payment commitment within anamount field 184.

The interface 180 is also shown to include a statement portion 188,which communicates to the payee user a total of unfunded commitmentsreceivable 190, a total funded commitments receivable 192, a totalcommitments receivable 194 and a risk-adjusted commitments receivabletotal 196, calculated in the manner described above.

In one embodiment of the present invention, the micropayment system 24my also allow a payee user to select from a list of eligible payor usersfrom which the payee user would prefer to receive a funding payment. Tothis end, FIG. 12 illustrates an exemplary payable interface 198, whichmay be presented to a payee user, advising the payee user that acommitments receivable balance exceeds a threshold that is eligible fora funding payment, and also presenting a list 199 of eligible payers,together with amounts that the eligible payers are eligible to pay. Thepayable interface 198 also includes a “proceed to payment service”button 176 that, in the manner described above, may initiate aninteraction between the micropayment system 24 and the settlement system22.

FIG. 13 shows a diagrammatic representation of machine in the exemplaryform of a computer system 200 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. in alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a personal computer(PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant(PDA), a cellular telephone, a web appliance, a network router, switchor bridge, or any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, white only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The exemplary computer system 200 includes a processor 202 (e.g., acentral processing unit (CPU), a graphics processing unit (CPU) orboth), a main memory 204 and a static memory 206, which communicate witheach other via a bus 208. The computer system 200 may further include avideo display unit 210 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 200 also includes analphanumeric input device 212 (e.g., a keyboard), a user interface (UI)navigation device 214 (e.g., a mouse), a disk drive unit 216, a signalgeneration device 218 (e.g., a speaker) and a network interface device220.

The disk drive unit 216 includes a machine-readable medium 222 on whichis stored one or more sets of instructions and data structures (e.g.,software 224) embodying or utilized by any one or more of themethodologies or functions described herein. The software 224 may alsoreside, completely or at least partially, within the main memory 204and/or within the processor 202 during execution thereof by the computersystem 200, the main memory 204 and the processor 202 also constitutingmachine-readable media.

The software 224 may further be transmitted or received over a network226 via the network interface device 220 utilizing any one of a numberof well-known transfer protocols (e.g., HTTP).

While the machine-readable medium 292 is shown in an exemplaryembodiment to be a single medium, the term “machine-readable medium”should be taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” shall also be taken to include any medium thatis capable of storing, encoding or carrying a set of instructions forexecution by the machine and that cause the machine to perform any oneor more of the methodologies of the present invention, or that iscapable of storing, encoding or carrying data structures utilized by orassociated with such a set of instructions. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals.

Thus, a method and system to enable the transfer of micropayments to avendor have been described. Although the present invention has beendescribed with reference to specific exemplary embodiments, it will beevident that various modifications and changes may be made to theseembodiments without departing from the broader spirit and scope of theinvention. Accordingly, the specification and drawings are to beregarded in an illustrative rather than a restrictive sense.

1. A method comprising: accessing a plurality of payment commitmentsmade to a payee by a plurality payors, the plurality of paymentcommitments contributing to a total commitment receivable value of thepayee; calculating the total commitment receivable value of the payeebased on the plurality of payment commitments made to the payee;determining a priority of the total commitment receivable value of thepayee relative to other total commitment receivable values of otherpayees; and initiating a payment process based at least in part on thepriority of the total commitment receivable value of the payee, thepayment process comprising a transfer of the total commitment receivablevalue from one of the payors to the payee.
 2. The method of claim 1, thedetermining of the priority of the total commitment receivable value ofthe payee being based at least in part on an identity of the payee. 3.The method of claim 1, further comprising placing into a funding queue aqueue entry representing the total commitment receivable value of thepayee, the funding queue comprising a plurality of queue entriescorresponding to the other total commitment receivable values of theother payees.
 4. The method of claim 3, the determining of the priorityof the total commitment receivable value of the payee being based on anelapsed period of time since the queue entry was placed in the fundingqueue.
 5. The method of claim 3, the determining of the priority of thetotal commitment receivable value of the payee being based on a firstin, first out priority scheme relating to the funding queue.
 6. Themethod of claim 1, further comprising determining whether the totalcommitment receivable value of the payee triggers a crossing of athreshold, the initiating of the payment process being at least in partin response to the determining of whether the total commitmentreceivable value of the payee triggers the crossing of the threshold. 7.The method of claim 6, the threshold being applied on one of a systemlevel, a user level, and a funding transaction level.
 8. The method ofclaim 1, the initiating of the payment process being at least in part inresponse to a total commitments payable value of one of the plurality ofpayors exceeding a threshold, the total commitment payable value beingbased on a plurality of payment commitments made by the one of thepayors.
 9. The method of claim 8, the initiating of the payment processbeing at least in part in response to the total commitment receivablevalue being satisfiable by the total commitment payable value.
 10. Themethod of claim 8, the initiating of the payment process being at leastin part in response to the total commitment receivable value crossing asecond threshold.
 11. The method of claim 8, the initiating of thepayment process further comprising receiving from the one of the payorsa selection of the payee.
 12. A system comprising: at least oneprocessor; and modules including instructions to be executed by the atleast one processor, the modules comprising: a micropayment database tostore a plurality of payment commitments made to a payee by a pluralityof payors, the plurality of payment commitments contributing to a totalcommitment receivable value of the payee; a calculation module tocalculate the total commitment receivable value of the payee based onthe plurality of payment commitments made to the payee; and a paymentallocation module to determine a priority of the total commitmentreceivable value of the payee relative to other total commitmentreceivable values of other payees, and to initiate a payment processbased at least in part on the priority of the total commitmentreceivable value of the payee, the payment process comprising a transferof the total commitment receivable value from one of the payors to thepayee.
 13. The system of claim 1, the priority of the total commitmentreceivable value of the payee being based on an attribute of the payee.14. The system of claim 1, further comprising: a funding queue to storea plurality of queue entries corresponding to the other total commitmentreceivable values of the other payees; the payment allocation module toplace into the funding queue a queue entry representing the totalcommitment receivable value of the payee.
 15. The system of claim 14,the priority of the total commitment receivable value of the payee beingbased on an elapsed period of time since the queue entry was placed inthe funding queue.
 16. The system of claim 14, the priority of the totalcommitment receivable value of the payee being based on a first in,first out priority scheme relating to the funding queue.
 17. The systemof claim 12, further comprising: a threshold assessment module todetermine whether the total commitment receivable value of the payeetriggers a crossing of a threshold; the payment allocation module toinitiate the payment process in response to the total commitmentreceivable value of the payee triggering the crossing of the threshold.18. The system of claim 17, the threshold assessment module to apply thethreshold on one of a system level, a user level, and a fundingtransaction level.
 19. The system of claim 12, the payment allocationmodule to initiate the payment process at least in part in response to atotal commitments payable value by one of the plurality of payorsexceeding a threshold, the total commitment payable value of the payorbased on a plurality of payment commitments made by the payor.
 20. Anon-transitory computer-readable medium comprising instructions that,when executed by at least one processor of a machine, cause the machineto perform operations comprising: accessing a plurality of paymentcommitments made to a payee by a plurality of payors, the plurality ofpayment commitments contributing to a total commitment receivable valueof the payee; calculating the total commitment receivable value of thepayee based on the plurality of payment commitments made to the payee;determining a priority of the total commitment receivable value of thepayee relative to other total commitment receivable values of otherpayees; and initiating a payment process based at least in part on thepriority of the total commitment receivable value of the payee, thepayment process comprising a transfer of the total commitment receivablevalue from one of the payors to the payee.